home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000054_icon-group-sender _Fri Feb 28 12:23:11 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Received: by cheltenham.cs.arizona.edu; Fri, 28 Feb 1997 12:48:34 MST
  2. Message-Id: <199702281720.AA15519@optima.cs.arizona.edu>
  3. X-Sender: lindsay@mail.rmc.ca
  4. X-Mailer: Windows Eudora Light Version 1.5.2
  5. Mime-Version: 1.0
  6. Content-Type: text/plain; charset="us-ascii"
  7. Date: Fri, 28 Feb 1997 12:23:11 -0500
  8. To: icon-group@cs.arizona.edu
  9. From: "John H. Lindsay" <lindsay_j@rmc.ca>
  10. Subject: Re: Icon and two-dimensional matching
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12. Status: RO
  13. Content-Length: 3767
  14.  
  15. At 08:17 1997 02 26 -0500, you wrote:
  16.  
  17. >[LONG post warning!]
  18. >
  19. >One of the things that strikes me from the partial set of responses
  20. >I've gotten regarding my queries "What's the largest Icon program
  21. >you've written?" and related, is the extent to which these reported
  22. >uses of Icon are examples of "new wines in old bottles".  That is to 
  23. >say, the applications remain pretty traditional, although Icon brings
  24. >its own means and methods to these problems.
  25.  
  26.  ...  big snip ...
  27.  
  28. You (and at least one other poster) rightly point out the nicities and 
  29. problems related to 2-dimensional extensions.  In the same vein, 
  30. I'll drop back to 1-dimensional ideas.
  31.  
  32. It has bothered me for a long time that the idea of _string_ has 
  33. only been applied to single characters in icon and many other 
  34. languages.  The problems of macro call recognition, local 
  35. syntax processing and partial pre-compilation are related to 
  36. handling strings of strings or strings of tokens (where a token is, 
  37. roughly, a structure consisting of a string with some extra 
  38. information).  HMP (High-Level Multipurpose Language or High-
  39. Level Macro Language - I.B.M.'s never-openly distributed macro 
  40. extension to PL/I) and ML/I (Brown's Macro Language/ I) allow for 
  41. recognition of essentially BNF-like patterns of such strings, but 
  42. not of string handling with similar operations to what we now use 
  43. freely with character strings, only restricted references to the 
  44. individual character string RESULTS (from tokens) of recognizing 
  45. such token strings.  No language seems to support directly or 
  46. even to support via a standard library or module, the 
  47. character-string-like or tree-like operations on strings of anything 
  48. else.  (I haven't yet gotten around to looking at TXL - Tree 
  49. Transformation Language - done just a few years ago at Queen's 
  50. University though, so I shouldn't say that quite yet.)  In the string 
  51. operations, I'm thinking not only of concatenation and extracting a
  52. copy of a substring, but of Icon and SNOBOL4-like pattern matching 
  53. with excursions into other code in the process a la unevaluated 
  54. expressions in SNOBOL4 pattern matching and extracting a copy 
  55. of or even a reference to (as a pseudovariable) of a matched 
  56. portion.
  57.  
  58. The worst part is that, currently, Icon lacks anything like SNOBOL4's 
  59. OPSYN that can be used to give unused unary prefix or binary infix 
  60. operators a meaning or a new meaning.  Fortunately, with 
  61. SNOBOL's polymorphic data, the ability to overload operators
  62. is implicit and it would be implicit in Icon too if Icon had an 
  63. OPSYN-like facility.
  64.  
  65. I would like to play with such ideas, and on more than just pencil 
  66. and paper.  The dodge of using functions works, but is not as 
  67. systactically simple or as expressive as using operators; hence, 
  68. it's harder to see underlying structure and problems.
  69.  
  70. For this type of end, I'd love to see the ability in Icon to create new 
  71. operators, and to extend and to redefine existing operators.   Even 
  72. though Icon has very many pre-defined operators, Individual 
  73. problems need more operators, and it seems to me that the lexical 
  74. rule for 'what's an operator' is simple.  I'd hope that the facility would 
  75. generalize the idea of prefix vs  postfix for unary operators with the 
  76. idea of 2-operator and n-operator binary and n-ary expressions; 
  77. such things seem to occur easily in natural language expressions.
  78. The scope of such extensions could be open to discussion, but 
  79. with record type definitons being global to a program, global scope
  80. might be appropriate.  I wouldn't mind having to code parentheses 
  81. to resolve ambiguities for this sort of thing.
  82. All the best !
  83.  
  84. John H. Lindsay,
  85. DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
  86. ROYAL MILITARY COLLEGE OF CANADA
  87. PO BOX 17000  STN FORCES
  88. KINGSTON  ON   K7K7B4
  89.